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FOREWORD 


Efficient management of the Large Area Crop Inventory 
Experiment (LACIE) dictates that effective controls of 
project activities be established. To provide a basis for 
effective control, documentation will be prepared, baselines 
will be established, and changes to the baseline will be sub- 
sequently controlled by tne proper management levels. 


The specific control documents which will be used are- 
defined in the LACIE Project Plan, LAP01. All elements of 
the LACIE project must adhere to these baselined control 
documents; and where it is considered that the requirements 
should be changed, the proper change request, accompanied by 
a full Justification, must be submitted to the proper man- 
agement level in accordance with established procedures. 
These documents will be maintained current by change notices 
and revisions, as required. Each change notice and/or 
revision will reference the applicable Change Control Board 
Directive (CCBD) which approved the change. 


This document, LACIE-00200, Volume VI-B, defines the 
LACIE System Performance Evaluation - Reports Integration 
(SPE-RI) requirements and has bee' prepared in accordance 
with the Instructions for Preparation of LACIE Requirements 
Documents , LAC1E-00100, Revision C, dated November 20, 197^. 
”Full-Up System" as used in this document is defined as < the 
system required to accomplish LACIE Phase II. In general 
the approach used in each section is to first specify the 
requirements of the "Full-Up System" and then to specify 
the requirements of any Interim systems by reference to 
specific paragraphs in the Full-Up System requirements sec- 
tions of the document. The LACIE project phases are defined 
in the LACIE Project Plan, LAP01. 


The organization responsible for the implementation o 
each requirement is defined in this document specified on 
individual requirement basis. 'Where the implementation 
responsibility a” plies to the complete section, the imple- 
mentation responsibility is specified after the section title. 
A "section" for the purpose of designating implementation 
responsibility is defined as being any numbered paragraph and 
all numbered r i v, agraphs . Where different Implementation 
responsibilities apply to different portions of a section. 
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the Implementation responsibility is specified on an indi- 
vidual paragraph or sentence basis, as applicable. All 
implementing organizations designated shall accomplish their 
implementation activities in accordance with the requirements 
specified heruJLn. a 

TJ. CLJJ 

R. B. MacDonald 

Manager, Large Area Crop Inventory Experiment 
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l.o functional rkcpcnsililitjed 


1.1 GENERAL 


The 3PE-RI subsystem will Insure that provisions ar' 
r.ade for the generation, statusing, and dissemination of 
reports within and between subsystems as required to operate 
th' subsystems and evaluate their performance. 


1.2 SFECIFIC 


1.2.1 Functional Responsibilities 


The SPE-R1 will be functionally responsible for: 

a. Defining the report types, coordinating formats, a ni 
determining the freauency of reports which must be 
generated for or by LACIE subsystems. 

b. Assuring that provisions are made for collecting, 
statusing, tracking, indexing, and distributing 
reports generated In support of the project and 
providing checkpoints for timeliness of generati n 
and distribution. 

c. Assuring that provisions for historical query of 
both electronically and manually generated reports 
are Instituted. 

d. Coordinating the definition of format requirements 
for new types of reporting and assuring compatibilit 
of requests with existing system capabilities. 

e. Assessing the impact of new requirements which are 
not system compatible and investigating possible 
alttrnatives in conjunction with the requester. 
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f. Coordinating the compilation of new or custom reports 
based on the call-up of either real-time or historical 
data. 

g. Providing for project overview and management reports 
as required or deemed necessary for the good of the 
project . 

1.2.2 Operational Responsibilities 


The SPE-P.l will be operationally responsible for: 

a. Providing status ard tracking information to LACIE 
users via status summary reports. 

b. Maintaining workflow overview to insure timely com- 
pletion scheduled subsystem reports. 

c. Piov. 4 iiftg working interface between subsystems in 
developing workaround methods when schedules are 
threatened because of system failures or because of 
input data/processed data anomalies. 

d. Providing support to SPE-EA and Earth Observations 
Division (ECD) data manager. 

e. Interfacing with project management to develop tools 
as required to insure adequate management monitoring 
capability. 
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2.0 APPLICABLE DOCUMENTS 


The following documents are applicable to the extent 
specified herein: 

1. LACIE Project Plan, LAP01, November 18, 1974. 

2. Instructions for Preparation of LACIE Requirements 
Documents; LACIE-C0100, Revision C, November 20, 
1974 . 
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3.0 FUNCTIONAL FLOW DIAGRAMS 

3.1 REPORTS INTEGRATION DEVELOPMENT 

3.1.1 Full-Up System 

The Functional flow diagram for Reports Integrati 
System development is shown In figure 1. 

3.1.2 Interim System 

Same as 3*1.1 



3.2 REPORTS INTEGRATION OPERATION 

3.2.1 Full-Up System 

3 .2.2 Interim System 
To be determined (TBD). 


PKECEOF'lo • 
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4.0 CONSOLIDATED REQUIREMENTS 


4.1 FULL-UP SYSTEM 


The following subparagraphs document the consolidated 
requirements of the Reports Integration activity for 
support/products from other LACIE functional elements. 


4.1,1 Electronic Daily Reports 
(Req'd. by CAMS, CAS, and YES; Cat. 1; Impl. resp.: ISRRS 


4. 1.1.1 Background . - The Classification and Mensurati 
Subsystem (CAMS), the Yield Assessment Subsystem (YES), and 
the Crop Assessment Subsystem (CAS) have identified require 
ments for a number of real-time daily electronic reporting 
types. At this writing, it is assumed that the actual trar. 
mission of these reports will be from the generating source 
to the EOD data manager who will then distribute them to th 
appropriate subsystems as required. However, a definite 
requirement exists for a comprehensive system for the statu 
and accountability of electronic daily reports. Since the 
potential exists for some 30,000 daily report types to be 
generated annually, it is obvious that an electronic book- 
keeping and accounting system is required to provide an 
accurate history of all reports generated for each sample 
segment . 


4. 1.1. 2 Report types .- Generic report types requiring 
status and tracking activity identified to date are as 
follows : 

1. Indexed Data Report 

2. Post Classification Report 
3 • Classification Map 

4. Cluster Map 

5. Segment Acquisition Status Matrix 

6. Other report types TBD 


PRECEDING H, .1 l-LAN* NUT ttfciv, 
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4.1. 1.3 Description of service required .- Since only 
the Indexed Data Report and the' Segment Acquisition Stat-c 
Matrix are recoverable from the Information Storage, Retrieva 
and Reformatting' Subsystem (ISRRS) electronic data base, 
provision must be made for manually recovering all other 
reports from the ISRRS nonelectronic data base as well as 
maintaining accountability of report generation and shipment 
to the Johnson Space Center (JSC)/EOD. 


4.1.2 Manually Acquired Data Ease Status Reporting 
(Req'd. by SPE-RI; Cat. 1; Impl. resp.: ISRRS) 


4. 1.2.1 Background . - In addition to maintaining an 
accountability system for electronically generated reports 
(sec. 4.1.1) an analogous system is required for nonelectror! 
reports entered into the ISRRS data base. 


4. 1.2.2 Data sources .- The following are generic data 
types which must be statused via the ISRRS data base. 

1. Crop Calendars 

2. Historical Climate Summaries 

3. Current Meteorological Conditions Report 

4. Summary Data Reports 

5. Historical Cropping Practices Report 

6. Other data types TBD 

4. 1.2. 3 Description of service required .- As part of it 
function, the nonelectronic ISRRS is required to provide 
storage and retrieval of the products listed above and to 
provide the summary data availability report. 
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4.1.3 Intensive Test Site Reports Status 
(Req'd. by SPE-RI; Cat. 1; Impl. resp.: ISRRS) 


It is highly desirable to maintain an accurate 
accountability of the number and kind of intensive test- 
site-related reports entered into the data base. The 
system is identical in concept to that advanced in 
sec. 4.1.2. 





4. 1.3.1 Data types .- Generic data types requiring 
status and tracking activity identified to date are as 
follows : 

1. Agricultural Stabilization and Conservation 
Service (ASCS) Land Use Inventory 

2. ASCS photographs (Field Boundary Survey) 

3. ASCS yield determination 

4. ASCS periodic observations (Crop Condition Surve 

5. Test site assessment reports 

6. Aircraft photograph coverage 

7. Synoptic weather data 

8. Other site data TBD 

4.1. 3 . <2 Description of service required .- See 
sec. 4. 1.2. 3). (Req'd. by SPE-RI; Cat. 1; Impl. resp.: 
ISRRS) 


4.1.4 Subsystem-Generated Output Reports 
(Req'd. by SPE-RI; Cat. 1; Impl. resp.: ISRRS) 


The requirement exists to maintain an accurate 
accountability for all subsystem-generated reports. 
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4. 1.4.1 Subsystem output report types .- Generic output 
report types requiring 3tatus and tracking activity identified 
to date are as follows: 

1. Electronically Aggregated Reports 

2. Monthly Crop Reports 

3. Monthly Crop and Assessment of Accuracy and 
Precision Reports 

4. Conventional Crop Rcport/LACIE Crop Report Comparison 

5. Production film converter (PFC) Segment Film Products 
Report 

6. System Usage Reports 

7. All other manually or electronically generated sub- 
system reports required as input to other subsystems 
or otherwise satisfy LACIE objectives. 


^.1.^.2 Description of service required .- Status and 
tracking of the report types described in section 4. 1.4.1 
requires that the ISRRS provide a record of each report; the 
date generated and related TED key parameters as appropriate. 
These data will then serve as the premise for the SPE-F.I 
Summary Status Reports. The Electronic Reports Accounting 
System (ERAS) will require the automatic generation in 
real-time of a report status record keyed by the completion 
of each electronically generated report. In addition, ISRRS 
is required to enter similar data for manually generated 
reports on a daily basis either through batch Jobs or by 
terminal entry. 



The storage and report formats are being finalized 
currently storage and retrieval capability will require 
minimum of the following parameters: 

a. 

Report type 


b. 

Report number 


c . 

Date of report 


d. 

Report media (microfiche, hard 

copy) 
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e. Segment, zone, region, nurr.ber(s) and/or 
country involved 

f. Good/no-good code 

g. Releasability code 

h. Releasability downgrading 

1. New releasability code 

2. Date changed 

3. Authority basis for change 


4. 1.4. 2.1 Storage: Physical disc storage areas are 

required. At this stage, finite definition of storage 
requirements is difficult to pin down; however, two areas 
can be described: (a) daily report status accumulation 

(real-time) within the ISRRS data base and (b) current month 
report status accumulation in the Reports Integration System 
ERAS data base (daily automatic dump from the daily report 
status accumulation). 


*1.1. 4. 2. 2 Status: Once the internal format can te 

established, tne daily report status storage area can be 
calculated using the following formulas: 

Phase I-C: (5-10 segments * 4 rpts.) + 50 manual rpts. 

expected per day 

• 

Phase I-D: (30 segments * 5 rpts.) + 25 manual rpts. + 

50 aggregated rpts. expected per day 

Full-Up: (100 segments * 5 rpts.) + 20 manual rpts. + 

160 aggregated rpts. expected per day 

a. The internal format can be established as basically 
the same requirement as for the daily status except 
for perhaps a shifting of record control (sorting) 
by segment number instead of report type/number. 

The monthly report status storage area requirements 
can be escalated using the formulas cited above 
except that each calculated result must be multi- 
plied by 22 - the average number of workdays/montn . 
If seven day/week operations are anticipated, then 
the multiplier should be increased to 31. 
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b. A historical tape will be required in order to 
dump the current month report status data, and 
erasure of the dl3c area for new accumulations will 
be required. In conjunction with this historic 
tape and others TBD, temporary disc file space is 
required to enter tape and/or manually available 
data and to provide a working area for quarter, 
semiannual, and annual aggregations of data and 
for graphic terminal compilation and display o r 
line and bargraphs. 

c. For trend analysis, a generalized statistics soft- 
ware package is required whereby values of 2 or 
more data parameters may be totaled and used to 
drive the line and/or bargraph displays cited 
above. The capability of overlaying (or over- 
writing) an existing display with additional data 
is required of the software. 

d. A graphics type terminal and a "total screen" type 
printer are required for the trend analysis ana for 
graphic compilations of data for use in combined 
manual/electronic reports. 


4. 1.4. 3 Report headers .- The basic information listed 
below is required for all the electronic daily report types. 

a. Where multiple reports are contained on a single 
fiche card, page 1 of that fiche card is to contain 
an index listing of all segment reports contained * 
on that fiche card. 

b. Only one report type is to c included per fiche; 

e.g., daily reports and classification maps would 
not be mixed on the same card. 

c. Where printer listings instead of (or in addition 
to) microfiche are produced, page 1 of the listing 
is to contain an index of the sample segments 
included in the body of the printout. 

d. The header of each fiche card or the first page of 
each tab run should include as a minimum the 
following. 
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1. Microfiche or hard copy record nunbt r ir. tr.e 

upper left corner: Each microfiche card r.u-t 

also be numbered uniquely in the header to 
allow for subsequent retrieval from the IMS 
manual data base: 

2. Date produced - upper right 

3. Type of report - center 

4. Releacability code - upper left 

e. A releasabillty code for each report type should t 
devised detailing to whom the report may be dis- 
tributed and whether or not the information con- 
tained in the report is proprietary ox* otherwise 
sensitive. This should be predicated on the higr.c 
classification of any report contained therein. P 
cedures for periodic or occasional downgrading ar.c 
authority to downgrade reports must be provided. 


4.1.5 Statusing and Tracking of Reports 


4. 1,5.1 background . - Part of the SPE-RI activities 
require that a system for reporting on the timeliness of 
report generation and dissemination be Instituted. Such a 
system would allow for the monitoring of the repox’t genera- 
tion schedules (i.e., frequency, required due dates, etc.). 
The SPE-RI function is to review this schedule at regular 
intervals and to report on problem areas or bottlenecks. 


4. 1 . 5 . 2 Information required (Req'd. by SPE-RI; 

Cat. 1} Irr.pl. resp.: all subsystems; RTEE, ASVB).- At a 

minimum, each subsystem and the RT&E are required to furnis 
SPE-RI with both a listing of reports they intend to genera 
and those they require, the frequency of generation, and a 
schedule o:i* completion dates. 


4. 1 . 5 . 3 Description of service required .- (a) trans- 
actions between suosystems by definition must pass through 
ISRRS; therefore, ISRRS is required to make provision for 
recording these transactions in the data base such that 
SPE-RI can interrogate for status updates. (See sec. 4.1.4 
(Req'd. by SPE-RI; Cat. 2; Impl. resp.: ISRRS) (b) Trans- 

actions from outside (as RT&E reports) do not necessarily 
have to pass through ISRRS. Accordingly, it is the respon- 
sibility of the requesting subsystem(s) to assure that CPE- 
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is suitably apprised of the existence of these reports (Req'u. 
by SPE-RI : Cat. 2; lr.pl. resp.: RT&E, ASVb staff). 


4.2 INTERIM SYSTEM 


4.2.1 Phase I-C 


4.2. 1.1 
developed in 


Electronic dally reports .- All requirements 
Sec . 4.1.1 apply for* the interim (I-C) system. 


4.2. 1.2 Manually acquired data base status .- All 
requirements developed in Sec. 4.1.2 apply for the Interim 
(I-C) system. 


4.2.1, 3 Intensive test site summary status reports . - 
All requirements developed ir. Sec. 4.1.3 apply the 
interim (I-C) system. 


4. 2. 1.4 Subsystem generated output reports .- The basic 
requirements developed in Sec. 4.1.4 apply to phase I-C. 

From a software development and reports statusinc standpoint, 
the functions to be carried out remain essentially the same 
as those described in Sec. 4.1.4. 



4. 2. 1.5 Statuclnr and tracking of reports .- The basic 
requirements developed in Sec. 4.1.5 apply. All requirements 
developed in Sec. 4.2.1 apply. 


4.2.2 Phase I-D 


All requirements developed in Sec. 4.2.1 apply. 
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5.0 SUBSYSTEM INPUT REQUIREMENTS 


Inputs required by the SPE-RI from other LACIE su 
and/or support elements are defined lr. the following 
subparagraphs . 


5.1 FULL-UP SYSTEM 

5.1.1 Generic SPE-Fil Input Requirements 
(Req'd. by SPE-RI; Cat. 2; Impl. resp.: ISRF.S) 


5. 1.1.1 Background. - The SPE-RI has the respor.si 
to status and track all data products input to the LAC 
system and all subsystem-generated output reports requ 
as input to other subsystems or otherwise required to 
LACIE objectives. In oraer to meet this requirement, 
must maintain cognizance of all data base transactions 
involving reports/products generated. 



5 . 1 . 1 . 2 Reports and data products requiring SPE-RI 
support . - Those report types and data product types 
requirin. status and tracking activity by SPE-RI identifies 
to date are as follows: 


a. Electronic Reports 

1. Indexed Data Report 

2. Post Classification Report 

3. Classification Map 
Cluster Map 

5* Segment Acquisition Status Matrix 

b. Manually acquired reports 

1. Crop Calendars 

2. Historical Cropping Practices Report 

3. Historical Climate Summaries 

4. Current Meteorological Conditions Report 

5. Summary Data Report 

c. Intensive Test Site Reports 

1. ASCS Land Use Inventory 

2. ASCS Photographs 

3. ASCS Yield Determination 

^ . ASCS Periodic Observations 
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5. Test Site Assessment Reports 

6. Aircraft Photographs 

7. Synoptic Weather Data 

d. System Usage Reports 

e. Ail other subsystem reports not previously identified 

f. All intersubsystem reports and products 


5« 1.1. 3 Si r.-HI I n put parameters .- Associated with each 
report type or aata product that SFE-RI will status arid track 
art certain key parameters that uniquely luentify each item. 
In adaition to utilizing these keys for identification pur- 
poses, srE-RI will perform various sorts on the keys in orcr:r 
to generate the status report types required by 2PE-RI users. 
Those keys established to date include the following: 

1. Type of report cr data product 

2. Number or other identification 

3. Date 
Media 

5. Segment(s), zones, regions, or 
countries involve^ 

6. Good/no-gocd code * 

7. Releasability code 

8. Releasability downgrading 
lnfc rr.ation 

9. Other keys T3D 


5.1.2 Statusing and Tracking of Reports 


5. 3.2.1 Background . - The SPE-RI intends to compile 
master schedules of reporting types to be generated ana to 
monitor ana report on the timeliness of reports generation 
and distribution. 
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5. 1.2. 2 Inputs required .- (Req'd. by SPE-RI ; Cat. 1; 
Impl. resp.: all subsystems, RT&E, A3VB staff). Each sub- 

system and the RT&E are to Identify (a) the ty*.e, frequency, 
format, and need dates of reports required as inputs, ar.d 
(b) the type, frequency, format, and anticipated completion 
dates of reports generated as outputs. 


5.1.2. 3 Reports between s u bsystems .- (Req'd. by SPE-RI ; 
Cat. 2; Impl. resp . : . All reports between subsystems 

are defined as flowing through 1SRRS. ISRRS is to strip cut 
and store in the data base for subsequent interrogation by 
SPE-RI Information on the type, completion date, and format 
(hard copy, microfiche, etc.) of reports passing through ISRRS 


5.1.3 SPE-RI Data Base Interface 
(Req'd. by SPE-RI; Cat. 2; Impl. resp.: ISRRS) 


Catalog functions within the ISRRS data base should be 
structured to accommodate real-time interactive terminal 
access having capability to provide displays and hard copy of 
each type of subject report or product sorted per predetermine 
key parameters. The capability to provide selected reports 
automatically on a periodic basis is required. Batch mode 
processing with access to the historical data base or archived 
data is required. It should be noted that SPE-RI does net 
require report contents or products per se, but rather key 
parameter sorts of the subject report/product title and Reader 
information. 


5.2 INTERIM SYSTEM 


5.2.1 Phase I-C 


5 • 2 . 1 . 1 Generic SPE-RI input requirements . - The 
requirements developed in section 5-1.1 apply for the phase I- 
interim system. 


5 .2. 1.2 Statuolnn and tracking of reports .- The require- 
ments developed in section 5.1.2 apply for the phase I-C 
interim subsystem. 
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5.2.2 Phase I-D 


O 


All requirements developed in section 5.2.1 apply. 
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6 . 0 SUBSYSTEM OUTPUT REQUIREMENTS 


Outputs from the SPE-RIS function will be provided to 
other LACIE elements as defined in the following subparagrap 


6 . 1 FULL-UP SYSTEM 


6.1.1 System Performance Evaluation 
Reports Integration 


The SPE-RI must be responsive to queries for status 
data from all levels of management including, but not 
limited to. Project Management, EOD Data Management, 
Research and Development Management, and all subsystems 
managers. The SPE-RI, per se , has no specific output 
product; the "product" is a display or printed listing 
showing the status of report generation of the other sub 
systems that were fed into the RIS Data Base via ISERS. 


6.1.2 SPE-RI Output Products 


The SPE-RI will generate upon demand or periodically 
several predefined Status Summary Reports. These reports 
will reflect historical or current status and tracking 
Information relating to subsystem report and product typ*es 
sorted per specified key parameters. Report and product 
types requiring SPE-RI activity are described in section 5. 


Generic Status Summary Report types identified to date 
include the following: 

1. Segment Classification Status 

2. Segment Film Products Status 

3. Manually Acquired Products Receipt Status 
Intensive Test Site Summary Report Status 

5. Electronically Aggregated Report Status 
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6. Monthly Crop Reports Status 

7. Monthly Crop and Assessment of Accuracy and Precision 
Status Report 

8. PFC Segment Film Products report status 

9. Conventional/LACIE Crop report status 

10. Other status summary reports TBD 

6.2 INTERIM SYSTEM 

6.2.1 Phase I-C 

The requirements as depicted in section 6.1.1 apply 
equally to Phase I-C. 

6.2.2 Phase I-D 

All requirements developed in section 6.2.1 apply. 



22 


C 



o 


7 . 0 INTERFACE DOCUMENTS REQUIREMENTS 


Each implementing organization will comply with the 
interface requirements specified in the following documents. 


7.1 INTERCENTER CONTROL DOCUMENTS 


Copies are required of all Intercenter Control Documents 
when finalized. 


7.2 INTERFACE CONTROL DOCUMENTS 


Copies of all Interface Control Documents for each 
subsystem are also required w--en generated or updated. 
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8.0 OPERATIONAL REQUIREMENTS AFFECTING 
THE SUBSYSTEM DESIGN 


The operational requirements of this subs>stem vary 
depending on the mode of operation and the data base(s). 


8.1 THROUGHPUT REQUIREMENTS 


Four distinct categories of queries/jobs can be 
identified: interactive, real-time; Interactive, monthly 

accumulations; interactive, demand; and batch Jobs. 


8.1.1 Interactive, Real-Time 
(Req'd. by SPE-RI; Cat. 2; Impl. resp.: ISRRS) 


Queries against the ISRRS data base will be Initially 
made 6 to 8 times per day in Phase I-C with an anticipated 
Increase to approximately 10 to 12 times per day by the 
"fully operational" system. 


8.1.2 Interactive, Monthly Accumulation 
(Req'd. by SPE-RI; Cat. 2; Impl. resp.: ISRRS) 


These queries against the ERAS monthly accumulation* 
data base will initially be made 4 to 5 times p»r day in 
Phase I-C with an anticipated increase to approximately 
15 to 16 times per day by the "fully operational" system. 

This increase will handle queries of reports status throughou 
the current month. Automatic batch runs to copy the daily 
reports status from the ISRRS data base to the ERAS monthly 
accumulation data base are required. 


8.1.3 Interactive, Demand 


Queries and data manipulations to be performed from the 
graphics terminal will require reading the data from histori 
tapes. These requirements must be initiated with the Phase 
system. 


PKfcC.fcDl.Nv . 
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8.1. 3*1 Historical data base (Req'd. by SPE-RI; Cat. 2 ; 
Inpl. resp.: lSRR3 1 ).- The historical data base will be ar. 

accumulation of the monthly data for annual periods. Agere ra- 
tion of the monthly data into quarterly (and later, semi- 
annual and annual aggregations) is required. Initially, such 
queries will be made 2 to 3 times per month in the Phase I-D 
with an anticipated decrease to 1 to 2 times per quarter by 
the "fully operational" system. The quantity of each type of 
report will be totaled for each subsystem to compile tabular 
displays/printouts. The compilation of graphics (bargraphs 
and line charts) representing these data is also required. 


8.1. 3.2 Subsystem requirements (Req'd. by SPE-RI; Cat. 2; 
Impl. resp.: ISRRS).- All subsystems are required to accumu- 

late statistical data including CPU + I/O times, manhours, ar.i 
budgetary data for the Performance Assessment Staff evaluations 
and trend analysis. Totaling of each type item by subsystem, 
is required to compile tabular dlsplays/prlntcuts and for tr.e 
compilation of graphics similar to those cited in para- 
graph 8. 1.3.1. Initially, such compilations are requires of 
the Phase I-C system at the rate of 1 to 2 per month per sub- 
system (e.g., 8 to lo total) and becoming 4 to 5 per quarter 
per subsystem by the "fully operational" system. 



8.1.4 Batch Jobs 


Batch jobs for this subsystem fall into two categories 
automatic Jobs and "demand" initiated jobs (directed from 
the remote terminal). 


8 . 1 . 4 . 1 Automatic batch Jobs (required by Phase 1-C) 
(Req'd. by SPE-RI; Cat. 2; Impl. resp . : ISRRS).- Automatic 

copying of the daily accumulation of the reports status from 
the real-time ISRRS data base into the reports integration 
data base (aisc-to-disc ) is required at the close of business 
each day. Additionally, the status of the daily reports is 
to be listed and routed to the reports integration by the 
means TBD. 


Automatic copying of the current months' reports integra- 
tion data base for historical purposes is required at the close 
of business on the last working day of each month. Provisions 
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to insure accurate transfer of data from the current data 
base to the historical data base prior to destroying the 
current data base snail be made. 


8. 1.^.2 11 Dercam 11 Jobs (required by Pnase I-C) (Req'u. : 

SFE-RI; Cat. 2; Inpl. resp.: ISRRS).- eriodically , the 

results of queries and tabulations of statistical data will 
be too lengthy to print economically at the remote terminal. 
The capability of Initiating a batch Job from the remote 
terminal to print such data on the computer's high-speed 
printer is required. Frequency of such requests is estimated 
to be one time per week by the Phase I-C system with an 
anticipated increase of 2 to 3 per week by the "fully pera- 
tional" system. 


8 . 2 RESPONSE TIME 

(Req'd. by 3PE-RI; Cat. 2; Impl. resp.: ISRRS) 


Response to interactive queries of 5 to 6 seconds is 
required. When demand tapes are required, a "wale" time rot 
to exceed 5 minutes for operator tape location, mounting, 
and temporary disc area loading is acceptable. Display of 
statistical data compilations requires response times of 
10 to 12 seconds for either tabular or graphic data. A 
2^4-hour response time to batch Job printouts is required 
whether or not the Job is initiated by cards or from a 
remote terminal. 


8.3 'RELIABILITY REQUIREMENTS 


Provisions to insure accurate transfer from the current 
working data base into the historical data base shall be 
made prior to destroying current data base entries. 

8.U SECURITY REQUIREMENTS 


A LACIE security plan will be prepared by each organisa- 
tion designated with implementation responsibility. The plan 
for each implementing organisation will define the specific 
measures that will be utilized by that organisation to comply 
with the LACIE security requirements. The LACIE securit/ 
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requirements will be defined by USDA and will be forwarded 
to the implementing organizations on receipt by the LACIE 
project manager. Each Implementing organization will submit 
its plan for approval to the LACIE Level III change beard 
within 90 days after its receipt of the USDA requirements. 
Operational security requirements are categorized as sensi- 
tive data security, data entry/changeability security, and 
files integrity. 



8.4.1 Sensitive Data Security 


The ERAS will contain reference to sensitive reports 
status including a releasability code; however, all sensitive 
data per se are being handled in the ISRRS. The SPE-RI, 
therefore, has no "sensitive data" storage requirements for 
this category of security measures. 


8.4.2 Data Entry/Changeability Security 
(Req'd. by SPE-RI; Cat. 2; Impl. resp.: ISRRS) 


All initial data entry into the reports integration ERAS 
is the result of report statusir.g by the ISRRS. The SFE-RI 
will require the capability to change some data in individual 
records, to delete some records, and to add some records to 
the ERAS. An example of changes includes the downgrading of 
sensitive reports - when downgraded and upon what authority. 
This downgrading vill usually be required against specific, 
historical tape records but could also occur against the 
current data base. Data entry/changeability, therefore, 
should be limited to status only parameters. 



8.5 DELIVERY REQUIREMENTS 


Report status printouts will be generated daily and can 
be picked up from a centrally located box as designated by 
ISRRS within JSC Building 17 not more than 24 hours after 
generation. Periodic courier service is required for any 
interbuilding transfer of computer printouts. 
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8.6 QUALITY CONTROL REQUIREMENTS 


The ISRRS is expected to exercise data quality control 
electronically of all data entry. The SPE-RI will •. 
a procedure to check the data visually in order to spot 
disparities and to coordinate corrections with ISRRS. 


8.7 OTHER OPERATIONAL REQUIREMENTS 


The SPE-RI does not anticipate any other operatlmal 
requirements at this tine. A LACIE quality assurance ; i 
will be prepared by each organization designated with ir. pie- 
mentation responsibility. The plan will cover a complete 
definition of all quality assurance functions that will L* 
implemented to assure maintenance of adequate quality levels 
Each plan will be submitted for approval to the LACIL Level 
change board within 90 days after requirements are baseline^ 
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9.0 


•UrJYJiF.:-: VF.r.iFicA: i::. red u i ebkekts 


Each organization decimated with implementation 
responsibility shall prepare a LACIE Veri ficatl cr. Plan 
including a complete definition of the verification func- 
tions proposed fcr verification of the pc. t ion of LA ZZ. f ■ 
which they are respcr.ricie . Each organization s:.all n.r.l 
a plan for approval to the LACIE Level III change board 
within 90 days after the requirements documents are ba 
-ined. As a minimum the verification plan shall inclu 
elements related to tr.e SPE-RI effort. However, at rr 
the SFE-RI verification requirements are TED.* 
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10.0 


TEST AI1D EVALUATION 


10.1 SPE-RI REQUIREMENTS 
(Req'd. by SPE-RI; Cat. 2; Ir.pl. resp.: ISRRS) 


The SPE-RI will require that a minimum of one rr.or.tn'.-: 
accumulation of highly controlled test data be entered Into 
the ISRRS cne month after the start of the Phase I-C 
operations . 

1. Five report st.atus records, each containing five- 
segments for each type of electronically generated 
report per day. 

2. Two report status records for each report type whi_;i 
is manually generated or received per day. 

3. Daily printout of report status test data (ir.rut 
format) for comparison with output data formats 
(displays ) . 

4. Weekly printout of report status test data as 
aggregated on the ERAS data base for evaluatir. - 
aggregated retrievals and display. 

i>. Demonstrate ability to correctly copy ISRRS daily 
reports status into the ERAS data base area daily. 
Also demonstrate the ability to correctly copy the 
ERAS monthly accumulation into the historical c.ata 
base. 

6. Printout of the month's aggregation of report statu 
data from both the real-time and the historical dat 
bases for comparison. 

7. Demonstration of timely Ability to "clear" or 
"erase" the monthly ERAS data base and the start 
of accumulation of the next month's worth of data. 


rhECfcDLNG PA .- LU\Nk N.OT 
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1C. 2 ENTERING AND ACCUMULATING 
DAILY REPORTS STATUS DATA 
(Req'd. by Sir-RI; Cat. 2; Impl. roan.: ISRRS) 


All daily ref rts status data must b«. ^nwered and 
Accumulated as generated ("live" data) at the earliest 
feasible time In the Phase I-C operations. An evaiuatir. 
(report of the subsystem to this point) should be compiett-t 
using a minimum of 2 weeks' data accumulation, and a formal 
report of the valuation shall be due not more than 2 weeks 
later. 


10.3 REQUIREMENTS AFTER THE FIRST 6 MONTHS' 
ACCUMULATION OF DATA 
(Cat. 2; Impl. resp.: SPE-RI) 


When 6 months' aata have been accumulated, SPE-RI will 
require : 

1. Complete alphabetical dump of the Reports Status 
History iata base for the previous t months operati 

2. Demonstration of the software ability to tabularise 

and accumulate totals for each segment used and upward 
aggregation reports (quarterly ana semi-annual), tc 
print the tabularised data, and to generate t!.< 
required corresponding histograms on the graphics 
terminal. . 


10.4 SUBSEQUENT DATA ACCUMULATION 
(Req'd. by SPE-RI; Cat. 2; Impl. resp.: ISRRS and RTEE) 


All "live" data collection and accumulation will contlou* 
throughout the evaluation and subsequent time periods. A 
separate historical data base may be used to accumulate the 
second 6 months' data provided that this tape and the first 
can later ce merged for an annual aggregation, statistical 
manipulations, and generation of histograms. Completion of 
an evaluation report of the subsystem to this point is 
required not later than the last working day cf the seventh 
month of operations. 
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10.5 REQUIREMENTS FOR HANDLING A 1-YEAR ACCUMULATION C : IAIA 


When e. full year's data have beer* accumulated , SPE-RI 
will require demonstration of the software to provide an 

rt Status aggregation* all statistical manipula- 
tions, taoulari-ations , and generation of all histogram.- 
previously cited, but for the year's operations. 


10.5.1 Documentation of Subsystems Inf ut and Output Format. 
(Req'd. by SPE-RI; Cat. 2; Ir.pl. resp.: ISRRS ar.d RTRP) 


The SPE-RI will require documentation of all subsystem 
input and output report formats including type(s) of media 
used to store/convcy all final products. Written notifica- 
tion to SPE-RI is required to confirm that the system's abilit;, 
to produce the report formats which rust be operational to cat 
has been verified. 



10.6 FINAL EVALUATION REPORT 
(Req'd. by SPE-RI; Cat. 2; Impl. resp.: ISRRS and RTLi) 


The final evaluation report is to be completed by tht 
last day of the thirteenth month of operations. 
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11.0 RESEARCH REQUIREMENTS 


11.1 HARDWARE 


Tne availability and connectabllity of a compatible 
graphics tenr.inal ar.d terminal printer needs to be researched, 
determined, and ordered in sufficient time to be Installed 
prior to tne beginning of Phase I-C operations. 


11.2 SOFTWARE 

(Req’a. by SFE-RI; Cat. 1; Impl. resp.: NASA/DSAD) 


The availability and applicability of existing software 
to generate the ERAS records automatically, to provide a 
means for entering receipts of manually generated data, to 
interactively change erroneous records, and to retrieve ana 
display the status of all reports needs to be researched. 


The availability and applicability of existing software 
to count (accumulate) statistical data from all subsystems, 
to tabularlse t’-.e results, and to generate/compile histograms 
from the data needs to be researched. 
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